HANOI UNIVERSITY OF SCIENCE AND TECHNOLOGY

MASTER THESIS

Research and Application of Elliptic Curve Veriable

Random Function in Blockchain Consensus Protocol

BUI NGOC PHUONG

Phuong.BN212250M@sis.hust.edu.vn

Major : Computer Science

Thesis advisor : Assoc. Prof. Nguyen Binh Minh

Signature of advisor

Department : Department of Computer Science

Institute : School of Information and Communication Technology

Hanoi, 10-2023

ĐT.QT12.BM12 Lần ban hành: 02 Ngày ban hành: 28/04/2023

CỘNG HÒA XÃ HỘI CHỦ NGHĨA VIỆT NAM

Độc lập – Tự do – Hạnh phúc

BẢN XÁC NHẬN CHỈNH SỬA LUẬN VĂN THẠC SĨ

Họ và tên tác giả luận văn : Bùi Ngọc Phương

Đề tài luận văn: Nghiên cứu và áp dụng hàm ngẫu nhiên có thể kiểm chứng

trên miền đường cong elliptic trong giao thức đồng thuận blockchain

Ngành: Khoa học máy tính

Mã số SV: 20212250M

Tác giả, Người hướng dẫn khoa học và Hội đồng chấm luận văn xác nhận tác

giả đã sửa chữa, bổ sung luận văn theo biên bản họp Hội đồng ngày 28/10 với các

nội dung sau:

STT

Nội dung chỉnh sửa

Trang

Làm rõ đề xuất so với các nghiên cứu có liên quan

37-38

Làm rõ ưu/nhược điểm của đề xuất và hướng tiếp cận

38-39

Mô tả rõ giải pháp và đóng góp

2-3

Sửa đổi validator set từ block h thành block h-1 theo ý kiến

góp ý của hội đồng

Bỏ số chương của phần mở đầu Introduction và phần kết luận

Conclusion

1,50

Rà soát, hiệu chỉnh các lỗi soạn thảo

Ngày 7 tháng 11 năm 2023

Giáo viên hướng dẫn Tác giả luận văn

CHỦ TỊCH HỘI ĐỒNG

MASTER THESIS ASSIGNMENT

1. Student’s information :

Name : Bui Ngoc Phuong.

Phone : 033 323 5666 Email: Phuong.BN212250M@sis.hust.edu.vn

Class : KH/CLC2021B

Affiliation : Hanoi University of Science and Technology.

Duration : 11/02/2021 - 31/05/2021.

2. Thesis title : Research and Application of Elliptic Curve Verifiable Random Func-

tion in Blockchain Consensus Protocol

3. Declarations/Disclosures :

I - Bui Ngoc Phuong - hereby warrants that the work and presentation in this the-

sis were performed by myself under the supervision of Assoc. Prof. Nguyen Binh

Minh. All the results presented in this thesis are truthful and are not copied from

any other works. All references in this thesis including images, tables, figures and

quotes are clearly and full documented in the bibliography. I will take full respon-

sibility for even one copy that violates school regulations.

Hanoi, date month year 2023

Author

Bui Ngoc Phuong

Acknowledgments

I would like to dedicate these lines to deliver my most sincere gratitude to those who have

helped and shaped the person that I am today.

I would like to offer my gratitude to my parents for raising, shaping, loving and sup-

porting me with all of their hearts. Their unconditional love and hope are what gave me

the motivation to walk on this long and arduous road.

For my time in Hanoi University of Science and Technology, I would also like to

express my sincerest thanks to Associate Professor Nguyen Binh Minh, who not only a

glimmering figure for me to follow, but also guided me towards new ideas, solved difficult

questions I had, and all in all had helped me overcome major obstacles ever since I was

still a student. Joining BKC Labs might as well could be the most correct decision in my

university years. Your guidance and encouragement, your supervision and knowledge are

what permitted me to complete this master thesis.

I would also want to extend my gratitude to ToV Chain brothers, who stayed by my

side through all the storm that we faced, and to all of the lecturers at Hanoi University of

Science and Technology, who offered me the knowledge and techniques to advance in my

field.

For those who I loved, and those who loved me, thank you again for always being on

my side, cheering and motivating me. I could not have done this without you.

Thesis advisor : Assoc. Prof. Nguyen Binh Minh Bui Ngoc Phuong

ABSTRACT

Blockchain technology has been undergoing a major shift recently, with the adoption of

Proof-of-Stake consensus mechanism in lieu of Proof-of-Work due to the former’s effi-

ciency and speed. One notable example of Proof-of-Stake is the Tendermint protocol,

which has been powering the entirety of Cosmos system - an ecosystem of multiple inter-

locked chains.

However, Tendermint’s choice of deterministically deciding the next block proposer

instead of utilizing a randomization function presents a huge window for malicious actors

to prepare and coordinate attacks on upcoming validator nodes, possibly crippling the at-

tacked chain, especially small chains with a few working nodes. Furthermore, randomized

number generation in this blockchain ecosystem still proves to be a challenge by reason

of blockchain’s inherent deterministic nature.

Aiming at the above problems, in this paper, we propose an improvement over Ten-

dermint consensus protocol, utilizing Elliptic Curve Verifiable Random Function, a fast

and secure pseudorandom generation algorithm suitable for deterministic systems like

blockchain. This novel approach will solve the problem of knowing the validator ahead of

time, whilst the verifiable random function module will be capable of supplying reliable

random numbers to the overlaying beacon chain - a blockchain capable of distributing

random numbers to users through smart contracts, and even other blockchains through

Cosmos’ InterBlockchain Communication Protocol.

The performed experiments with a prototype blockchain using the enhanced consensus

protocol demonstrated that the new consensus protocol improves Tendermint’s resilience

against network-layer attack vectors, while still maintaining adequate fairness and perfor-

mance.

Keywords: blockchain, consensus protocol, elliptic curve, verifiable random func-

tion, randomness, tendermint, chainlink, beacon chain

Contents

Abstract ii

List of Figures iv

List of Tables vi

List of Acronyms viii

Introduction 1

1 Related Works 4

1.1 Blockchain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2 Proof-of-Stake Consensus Protocol . . . . . . . . . . . . . . . . . . . . . 5

1.2.1 Proof-of-Stake . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.2.2 Tendermint Consensus Protocol . . . . . . . . . . . . . . . . . . 7

1.3 Elliptic Curve Digital Signature . . . . . . . . . . . . . . . . . . . . . . 8

1.4 Elliptic Curve Verifiable Random Functions . . . . . . . . . . . . . . . . 12

1.4.1 Verifiable Random Functions . . . . . . . . . . . . . . . . . . . 12

1.4.2 ECVRF main functions . . . . . . . . . . . . . . . . . . . . . . . 13

1.4.3 ECVRF auxilliary functions . . . . . . . . . . . . . . . . . . . . 15

1.4.4 Security Properties . . . . . . . . . . . . . . . . . . . . . . . . . 17

1.4.5 Chainlink’s application of ECVRF . . . . . . . . . . . . . . . . . 17

2 Possible Attacks on Blockchain System 19

2.1 Attack Vectors on Blockchain . . . . . . . . . . . . . . . . . . . . . . . 19

2.2 Peer-to-Peer network-based Attacks . . . . . . . . . . . . . . . . . . . . 20

2.2.1 Distributed Denial-of-Service . . . . . . . . . . . . . . . . . . . 20

2.2.2 Sybil Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20

2.2.3 Eclipse Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.4 Routing Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

iii

2.3 Possible Attack Scenarios on Deterministic Proposer Selection Algorithm 22

2.3.1 Eclipse Attack Scenario on Deterministic Proposer Selection Al-

gorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

2.3.2 DDoS Attack Scenario on Deterministic Proposer Selection Al-

gorithm . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24

2.4 Possible Attack Scenarios on Weak Randomization Algorithm . . . . . . 26

2.5 Precedents . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.1 Network-layer Attack . . . . . . . . . . . . . . . . . . . . . . . . 27

2.5.2 Weak Randomization Attack . . . . . . . . . . . . . . . . . . . . 27

2.6 Solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28

3 Designing the Consensus Protocol 29

3.1 Proposal and PreVote Processes . . . . . . . . . . . . . . . . . . . . . . 29

3.2 Random Module and Beacon Chain . . . . . . . . . . . . . . . . . . . . 35

3.3 Proposed Method Compared To Related Works . . . . . . . . . . . . . . 37

3.3.1 Algorand . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37

3.3.2 Polkadot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38

3.4 Method Advantages and Disadvantages . . . . . . . . . . . . . . . . . . 38

4 Implementation and Evaluation 40

4.1 Prototype Blockchain Creation . . . . . . . . . . . . . . . . . . . . . . . 40

4.2 Environmental Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.3 Correctness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.4 Fairness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.5 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

Conclusion 50

References 54

Appendices 55

A Prototype blockchain architecture 55

List of Figures

1.1.1 A simple blockchain model . . . . . . . . . . . . . . . . . . . . . . . . . 4

1.2.1 Energy consumption rate of Bitcoin and Ethereum (13) . . . . . . . . . . 6

1.2.2 Overview of Tendermint’s state machine (25) . . . . . . . . . . . . . . . 8

1.4.1 Chainlink’s VRF model (10) . . . . . . . . . . . . . . . . . . . . . . . . 18

2.2.1 Sybil attack example . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.2.2 Routing attack example . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

2.3.1 Normal operation of validators and proposer at height h . . . . . . . . . . 23

2.3.2 Eclipsed operation of validators and proposer at height h . . . . . . . . . 23

2.3.3 DDoS operation of validators and proposer at height h round 0 . . . . . . 24

2.3.4 DDoS operation of validators and proposer at height h round 1 . . . . . . 25

2.4.1 Weak randomness possible attack scenario . . . . . . . . . . . . . . . . . 26

3.1.1 Consensus process at a given block height h . . . . . . . . . . . . . . . . 29

3.1.2 Block structure of a VRF-enabled block . . . . . . . . . . . . . . . . . . 34

3.2.1 Random module design . . . . . . . . . . . . . . . . . . . . . . . . . . . 35

3.2.2 Example lottery design . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.1.1 Block struct in modified Tendermint Core . . . . . . . . . . . . . . . . . 41

4.1.2 Vrf struct in modified Tendermint Core . . . . . . . . . . . . . . . . . . 41

4.1.3 Vrf struct in modified Tendermint Core . . . . . . . . . . . . . . . . . . 42

4.3.1 Average block formation time under coordinated DDoS attack of Tender-

mint consensus protocol . . . . . . . . . . . . . . . . . . . . . . . . . . 43

4.3.2 Average block formation time under coordinated DDoS attack of VRF-

enabled consensus protocol . . . . . . . . . . . . . . . . . . . . . . . . . 44

4.4.1 Random beacon chain’s scatter plot of node selection over 1000 blocks

for 4 nodes, each with 1 voting power . . . . . . . . . . . . . . . . . . . 45

4.4.2 VRF-enabled consensus protocol’s percentage of node selection over 9852

blocks for 4 nodes, each with 1 voting power . . . . . . . . . . . . . . . 46

4.4.3 VRF-enabled consensus protocol’s percentage of node selection over 10224

blocks for 4 nodes, with voting powers equal to 1, 3, 5, 7 respectively . . 46

4.5.1 VRF-enabled consensus protocol’s node0 block formation time measure-

ments over length of 5000 blocks . . . . . . . . . . . . . . . . . . . . . . 48

4.5.2 VRF-enabled consensus protocol’s node1 block formation time measure-

ments over length of 5000 blocks . . . . . . . . . . . . . . . . . . . . . . 49

A.0.1Prototype blockchain overall architecture . . . . . . . . . . . . . . . . . 55

List of Tables

1.3.1 Resistance of secp256k1 and CurveEd25519 to cryptanalytical attacks (16) 11

4.5.1 Average block finalization duration of nodes over 10000 blocks (in ms) . 47

vii

List of Acronyms

DSA

Digital Signature Algorithm.

ECDSA

Elliptic Curve Digital Signature Algorithm.

ECVRF

Elliptic curve verifiable random function.

POS

Proof-of-Stake.

POW

Proof-of-Work.

VRF

Verifiable Random Function.

viii

Introduction

Problem overview

In 2008, a paper called ”Bitcoin: A Peer-to-Peer Electronic Cash” was published by

Satoshi Nakamoto, which proposed a novel type of decentralized system called blockchain

(33). The underlying infrastructure of Bitcoin’s blockchain relies on Proof-of-Work (PoW)

consensus protocol, where block builders (termed miners by the blockchain) compete for

the construction of the next block and the corresponding reward, and PoW has been the

go-to consensus mechanism for alternative chains such as Ethereum.

However, Proof-of-Stake (PoS) consensus protocol and its variants have been steadily

being chosen instead of Proof-of-Work, thanks to their efficiency at generating blocks and

their speed of reaching consensus, allowing for greater versatility for blockchain networks

while still maintaining fairness in reward distribution between block builders (30) (32).

One of the prominent variants of PoS is called Tendermint, which is a Byzantine Fault

Tolerant (BFT)-style PoS mechanism (25). Tendermint is widely adopted in the Cosmos

ecosystem, which in turn is a network of interlocked chains that could communicate with

each other using Cosmos’ Inter Blockchain Communication (IBC) protocol (26) .

Yet, a possible problem of Tendermint lies in its choice of selecting future validator

nodes for block proposals. The consensus protocol opted to use an algorithm to determin-

istically pick the validator node to propose a block for a chosen block height based on the

number of validators and the stake each validator has staked. As a result, malicious actors

have full knowledge about the sequence of block proposers ahead of time, and could pos-

sibly orchestrate distributed attacks (e.g. Distributed Denial of Service (DDoS) or Eclipse

Attack) against nodes right before they are selected to propose the block for the current

height. Repeated attacks on various nodes will severely delay the consensus time and pos-

sibly cripple the entire chain as a result, of which small chains with low node counts are

especially more vulnerable.

On the other hand, although PoS in general and Tendermint in particular could solve

some of PoW problems such as energy wastefulness, due to blockchain’s inherent de-

terministic nature, the answer for the outstanding issue of reliably generating random

numbers within the blockchain remains elusive (14), (4). Chainlink’s attempt to solve

this problem, that is utilizing an outside network to supply chains with Verifiable Random

Number (VRF) (10), theoretically could work on any chain, but this leaves smart contracts

and distributed applications heavily relying on a third party service. Moreover, Chainlink

requires specialized smart contracts deployed on the target blockchain, which could render

Chainlink unsuitable for the Cosmos Ecosystem due to its multiple chains nature, since

not every chain in the Cosmos Ecosystem is capable of running smart contracts (i.e. the

Cosmwasm module - Cosmos’ implementation of smart contracts - is not installed for that

chain). Meanwhile, the demand for random numbers on blockchain is quite big. Chain-

link’s VRF Coordinator on Binance Smart Chain - the smart contract that governs the

dispense of random numbers - records as many as 5000 requests per day (2). Thus, Cos-

mos Ecosystem would greatly benefit from having a source of randomness that is reliable

and fast within its vast network - in other words, a random beacon chain - a blockchain

that is capable of distributing verifiable random numbers through smart contracts, or to

other blockchains via the InterBlockchain Communication Protocol.

Goal of esis

In this thesis, we will introduce the concepts of blockchain, Proof-of-Work, Elliptic Curve,

Verifiable Random Function, then evaluate the outstanding problems in Proof-of-Stake

blockchain consensus protocol, in particular Tendermint, and randomness generation in

blockchain in general.

Next, this thesis will research elliptic curve digital signatures and elliptic curve ver-

ifiable random function, as well as selecting the best elliptic curve with highest security

and efficiency, and then implement them into the consensus protocol, evaluate its security,

and use this to build a random beacon blockchain.

Finally, this thesis will demonstrate a prototype blockchain using VRF-enabled cons-

esus protocol, then evaluate different metrics to ensure the correctness, fairness, and per-

formance of said consensus protocol compared to Tendermint.

esis Contributions

The works presented in this thesis bring the following contributions:

1. Improving Tendermint’s consensus protocol, by adding a VRF generation and ver-

ification protocol on block creation for choosing the next proposer.

2. Proposing a random beacon chain design based on the random number generated by

the VRF protocol, to be used by smart contracts within the VRF-enabled blockchain

and other smart contracts within the Cosmos Ecosystem via IBC.

3. Improving Chainlink’s VRF by using a more secure elliptic curve.

Main Content and Structure of esis

The remainder of this thesis is structured as follows. In Chapter 2 , we will provide in-

formation about background knowledge related to the proposed model, namely Proof-of-

Stake, Tendermint, Verifiable Random Function, Elliptic Curve. Chapter 3 will provide

information on possilbe attack vectors on blockchain network, including attacks against

the network layer and against the weak randomness of blockchain. The proposed model

design will be presented in Chapter 4, and the implementation and evaluation of the de-

sign will be demonstrated in Chapter 5. Chapter 6 will conclude our research and outline

future works.

Chapter 1

Related Works

In this chapter, we will introduce related works to the thesis’ idea. In more detail, Section

1.1 will introduce the concept of blockchain. Section 1.2 will introduce the Proof-of-Stake

consensus, protocol, and Section 1.3 will demonstrate the elliptic curve digital signature,

which will be helpful in Section 1.4, where we learn about Elliptic Curve Verifiable Ran-

dom Function, its algorithm and its application, so that we could discuss further in Chapter

1.1 Blockchain

A blockchain is a decentralized, distributed and public digital ledger that is utilized to

record transactions and share them among many computers in a vast array of comput-

ers. As per its name, blockchain is composed of ”blocks” which are linked together like

a ”chain”, consequently, changing a ”block” means severing the link to all subsequent

blocks down the line, which grows increasingly difficult after each new block is added

onto the blockchain.

Figure 1.1.1: A simple blockchain model

Figure 1.1.1 explains a simple model of the blockchain. Block 1 holds the hash of

block 0, and block 2 holds the hash of block 1, and so on. To successfully alter block 1’s

data, an adversary would need to alter the block 2, then block 3, ... until the very end of

the blockchain.

A blockchain is composed of three main components, namely ”block”, ”node”, and

”consensus mechanism”.

• Block is the foundation of the blockchain, containing transactions, blockhash, pre-

vious blockhash, timestamp, nonce. The identification of the block are the block

height number and the blockhash, which are used to link blocks together. Altering

one block will cause a cascading effect, requiring the attacker to alter all subsequent

block to avoid being detected by the system, which is increasingly difficult as more

blocks are added onto the system.

• Node is the body of decentralization in blockchain ecosystem. Nodes hold infor-

mation about the blockchain, ,ensure that peers are kept updated about the state

of the blockchain in an unanimous manner (.i.e anti-fragmenting), and ensure the

blockchain acquires high availability.

• Consensus Mechanism. As nodes need to ensure the unanimity of the blockchain, a

consensus mechanism is required. Historically, the de facto consensus mechanism

is Proof-of-Work, which requires participants - or ”miners” - to compete for the

creation of the next block, but there are now more consensus mechanism emerged

such as Proof-of-Stake, Proof-of-History, Proof-of-Authority which could achieve

higher energy efficience and faster speed.

1.2 Proof-of-Stake Consensus Protocol

1.2.1 Proof-of-Stake

As described in Section 1.1 blockchain is a distributed ledger of records that is shared

between network participant, or so-called ”nodes”, thus it requires nodes to unanimously

agree upon the next set of records - or in formal term, requires a consensus protocol.

There are many different kinds of consensus protocol, in which the most well-known

is Proof-of-Work consensus protocol, coined by Satoshi Nakamoto, and used in their cre-

ation, the Bitcoin blockchain network. But in recent years, Proof-of-Stake consensus pro-

tocol, where block creator is chosen based on the amount of ”stake” they have put into

the consensus mechanism, has been slowly but steadily replacing Proof-of-Work proto-

Figure 1.2.1: Energy consumption rate of Bitcoin and Ethereum (13)

col, where nodes compete with each other for being chosen as the block creator through

”work”, as the choice of consensus for building blockchain, due to the former’s superior

speed and energy efficiency compared to the latter.

In more details, in a Proof-of-Stake consensus protocol, instead of consuming vast

amount of energy competing to find the next ”hash” of the next block, participants will

elect a leader to act as the block proposer for the next block based on the stakes participants

have staked in the protocol.

Due to this block creation method, Proof-of-Stake enjoys exceptionally high energy

efficiency compared to Proof-of-Work. In particular, Bitcoin energy consumption rate is

14 gigawatts, and Ethereum Proof-of-Work energy consumption rate is 6 gigawatts. This

figure will only become higher and higher over time because block creation difficulty is

ever increasing, in turn the blockchain will requires more hash power to compute the next

block hash.

On the other hand, Proof-of-Stake mechanisms also enjoy superb transaction confir-

mation speed compared to Proof-of-Work, which is measured through Transaction per

Second (TPS). TPS can be computed as follows:

T P S =

T x

× B

cft

(1.1)

where B

is the average size of a block, T x

is the size of a transaction, and B

cft

is the

average confirmation time of a block. In the case of Bitcoin, its block’s size is 1MB, its

confirmation time is around 10 minutes (or 600 seconds), and average transaction size is

250 bytes, so its TPS is around 6 transactions per second. Proof-of-Stake protocols are not

weighted down by the limitations imposed on Bitcoin network, and on average PoS pro-

tocols enjoy vastly superior TPS compared to Bitcoin, for example: Binance Smart Chain

can handle around 150 TPS, Algorand up to 875 TPS, and Ethereum after the changeover

to Proof-of-Stake has a TPS count of 100.000 in theory.

Although there exist many different methods of choosing the next block proposer for

PoS, such as the Follow-the-Satoshi (FTS) method utilized by Tezos(5) or Ouroboros(24),

or a weighted round robin algorithm utilized by Tendermint (31), a proposer selection

method should satisfy two essential properties (6), that are:

1. Determinism, which means at given validator set V, block height h and round r,

the function select(V, h, r) will return the same value, and provides that blockchain

state is replicated.

2. Fairness, which means given a validator set V with total voting power of P, a val-

idator v with a voting power of p should be elected with a frequency of

over an

arbitrary long time.

1.2.2 Tendermint Consensus Protocol

In 2014, Kwon proposed a novel protocol called Tendermint that implements the Byzan-

tine Fault Tolerant Proof-of-Stake scheme for confirming blocks (25). This protocol at-

tempts to solve the ”nothing at stake” problem of practical byzantine fault tolerance (PBFT)

protocols, by making validators actually need to stake some of their assets to gain the right

to vote for a new block, and they will be penalized if caught performing malicious acts.

The operation flow of Tendermint runs as follows: There are three steps in each round,

namely Propose, Prevote, and Precommit. In Propose step, a deterministic round-robin

algorithm is used to determine the proposer of the next block, and after the new block has

been proposed, the validators will vote for that block in the Prevote step. If more than 2/3

of the voting power voted for a particular block, the consensus will enter Precommit step

and will attempt to commit the validated block to the blockchain, thereby confirming all of

the transactions included in that chain. If the system fails to reach a consensus (.e.g. less

than 2/3 of the voting powers voted for that block, or more than 2/3 of the voting power

broadcasted a nil vote), then a new round will begin until a new block is formed.

Tendermint is proven to be secure under the assumption that the network is partially

synchronized as long as at least 2/3 of the voting power is honest. The protocol enjoys

relatively high transaction throughput and low transaction confirmation time, therefore,

it is currently the backbone of Cosmos Ecosystem, a network of blockchains built from

Cosmos-SDK that are able to communicate with each other through the IBC protocol. Al-

Figure 1.2.2: Overview of Tendermint’s state machine (25)

though the protocol is proven to be secure against cryptographic attacks, the deterministic

nature of the round-robin proposer selection algorithm creates a window of opportunity

for attackers to cripple the operation of the blockchain.

1.3 Elliptic Curve Digital Signature

In blockchain systems, Elliptic Curve Digital Signature Algorithm (ECDSA) has been

used predominantly for different cryptographic procedures, such as verifying transac-

tions and creating digital signatures. ECDSA is derived from Digital Signature Algo-

rithm (DSA) using a Koblitz elliptic curve, which is secp256k1 in Ethereum and Bitcoin

blockchains (18). The elliptic curve used for ECDSA, which is also utilized in the Chain-

link’s VRF system, is the elliptic curve secp256k1, which is defined by the Standards for

Efficient Cryptography Group with the following parameters:

• P rime number p = 2

256

− 2

− 1

• Curve equation y

= x

+ 7

• Generator point G = (55066263022277343669578718895168534

326250603453777594175500187360389116729240,

3267051002075881697808308513

0507043184471273380659243275938904335757337482424)

• Order n = 115792089237316195423570985008687907852

837564279074904382605163141518161494337

ECDSA comprises of three steps: generating key pair, signature and verification.

1. Key Generation:

(a) Picks a random number i in the range of [0...n-1],

(b) Computes Q = (x

, y

) = iP on the curve secp256k1

2. Signing: Given an input message m to be signed, the private key i and hash func-

tion H

(a) Picks a random number k in the range of [1...n-1],

(b) Computes G = (x

, y

) = kP on the curve secp256k1

mod n. If r = 0, recomputes G and r with a new k.

(d) Computes signature s = (r + h ∗ a)

(e) Computes s ≡ k

−1

(H(m) + dr) mod n

(f) Returns the signature pair (r, s)

3. Signature verification: The algorithm to verify a ECDSA signature takes a mes-

sage msg as an input, the pair (r,s) obtained from the signature and the publicKey

corresponding to the signer’s privateKey. The output is boolean value: valid or

invalid signature. It works as follows:

(a) Computes input e ≡ s

−1

mod n

(b) Computes u

= eH(m) mod n and u

≡ er mod n

, y

) = u

P + u

Q on the curve secp256k1

(d) Verifies if x

≡ r mod n

In 2007, Edwards published a new normal form for elliptic curves (20), then Bernstein

et al. generalized this Edwards form to twisted Edwards curves (9) with the equation:

+ y

= 1 + dx

(1.2)

where d ∈ k\(0, 1). The sum of two points (x

, y

) and (x

, y

) on a twisted Edwards

curve is

, y

) + (x

, y

) = (

+ y

1 + dx

− x

1 − dx

) (1.3)

where the point (0,1) is the neutral element for addition, and an inversion of (x

, y

) returns

(−x

, y

In 2009, Bernstein proposed Curve25519 (7), which Bernstein also studied and con-

firmed its security and efficiency. This is the basis of Ed25519, a twisted Edwards form

representation of Curve25519, which is used to construct the digital signature Ed25519.

This curve has the following paramenters

• P rime number p = 2

255

− 19

• Curve equation − x

+ y

= 1 −

121665

121666

• Generator point G = ((151122213495354007725011514095885315114

54012693041857206046113283949847762202 ,

4631683569492647816942839400347516314130799

3866256225615783033603165251855960)

• Order n = 2

252

+ 27742317777372353535851937790883648493

Ed25519 also comprises of three steps: generating key pair, signature and verification.

Given input message m and a hash function H that produces a 2b-bits.

1. Key Generation:

(a) Generates a random number k which is in the range of [0...n-1],

(b) Computes H(k) = (h

, ..., h

2b−1

) in binary representation

b−2

∑

b−3

i=3

(d) Computes the public key A = a ∗ G on the curve

2. Signing: The ECDSA signing algorithm takes a message msg as an input, com-

bined it with privateKey and a hash function H. It works as follows:

(a) Compute r = H(h

, ..., h

2b1

, m) as an integer modulo n.

(b) Computes a random point R = r ∗ G on the elliptic curve.

(d) Computes signature s = (r + h ∗ a)

(e) Returns the signature pair (R,s)

3. Signature verification: The algorithm to verify a Ed25519 signature takes a mes-

sage msg as an input, the pair (R,s) obtained from the signature and the publicKey

corresponding to the signer’s privateKey. The output is boolean value: valid or

invalid signature. It works as follows:

(a) Computes input: h = H(R, A, m) as an integer

(b) Computes U = 8sB on the curve Ed25519

(d) Evaluates if U = V

Meryem et al. analyzed and evaluated Ed25519 against secp256k1, and confirmed

that Ed25519 performs equally or better in at least two different methods of attack on

the cryptographic level, and statistically performs faster than secp256k1 in both key pair

generation and verification (16).

In more details, it is shown that Ed25519 protocol is more resistant to complex-multiplication

field discriminants and Pollard’s rho attack than secp256k1, and is equally resistant to

other types of attacks, as shown in Table

Table 1.3.1: Resistance of secp256k1 and CurveEd25519 to cryptanalytical attacks (16)

Attack Attack condition Resistance of

secp256k1

Resistance of

CurveEd25519

CM field discriminants |D| > 2

100

| < 2

| > 2

254

Pohlig-Hellman n with small fac-

tors

is prime n

is prime

Pollard’s rho small

√

nπ

≥ 2

255

large

≥ 2

254

large

j-variant j = 0 j = 0 j = 0

Anomalous n = p n

= p

Frey-Rück n | (p

− 1) for

k ≤ 30

∤ (p

− 1) n

∤ (p

− 2)

MOV n = p + 1 n

= p

+ 1 n

= p

+ 1

It is also proven that computing on Ed25519 is more efficient than secp256k1, which

is inherently valued in the integration of Ed25519 into the blockchain space, which will

be discussed further in the design section.

1.4 Elliptic Curve Veriable Random Functions

1.4.1 Veriable Random Functions

Blockchains generally function in a deterministic and transparent manner, every state of

a blockchain is public and can be verified by any entity through nodes. Thus, generating

unpredictable randomized numbers on blockchain remains a daunting task. A candidate

solution for solving this dilemma is called Verifiable Random Function (VRF), which was

proposed by Micali et al. (29), wherein an entity could generate a pseudo-random number

by utilizing a secret key S

, and in turn, can prove the validity and correctness of such

number by revealing the proof π and its public key P

In more details, a Verifiable Random Function works as follow:

1. The Prover hashes an input alpha using VRF secret key S

to obtain and output

beta

beta = V RF _hash(S

, alpha) (1.4)

. This algorithm is deterministic, meaning given input alpha and S

, the result is

always beta.

2. The Prover also computes a proof π that proves beta is the correct output of V RF _hash:

π = V RF _prove(S

, alpha) (1.5)

3. This value π allows anyone to directly computes the output β by using:

beta = V RF _proof_to_hash(π) (1.6)

4. The Verifier then is capable of verifying that beta is the correct VRF hash of input

α by running the verify function with input alpha, proof pi and the Prover’s public

key P

is_valid = V RF _verif y(P

, alpha, π) (1.7)

which returns (true, beta ) if the output beta is indeed computed in a valid manner.

A secure VRF model should satisfy four distinct properties (19), that are:

1. Pseudorandomness, which means the output y should appear to be statistically ran-

dom, despite being the result of a deterministic function. A well constructed VRF

would satisfies the ”full pseudorandomness” properties, meaning an adversary can-

not determines the output beta even when he is able to choose the input alpha, and

cannot reverse engineer output beta

after observing n-1 pairs of previous outputs

beta

′

and proofs pi

′

2. Verifiability, which means the proof π will always be able to return true if the com-

putation is correct.

3. Uniqueness, which means for each P

and input x, there cannot be different proofs

and π

for different results y

and y

. More precisely, the adversary cannot

find a VRF public key P

, a VRF input alpha and two proofs π

and π

such that

V RF _verif y(P

, alpha, π

) outputs (true, beta

) and V RF _verif y(P

, alpha, π

)

outputs (true, beta

4. Collision Resistance, which means there cannot exist two distinct inputs x

and

that result in the same output y. More precisely, an adversary cannot find a

VRF public key P

, two different inputs al pha

and alpha

and two proofs π

and π

such that such that V RF _verif y(P

, alpha, π

) outputs (true, beta

) and

V RF _verif y(P

, alpha, π

) outputs (true, beta

) and beta

= beta

A particularly efficient construction of VRF is called Elliptic Curve VRF, where the

secret-public key pairs are derived from elliptic curves (17). This version of VRF has been

proven to be fast, secure, and satisfies all of the criteria denoted above. The algorithms

for ECVRF generation is denoted as follows:

1.4.2 ECVRF main functions

For our applications which will be applied in Chapter 4, these algorithms will utilize

the specifications of ECVRF ciphersuite listed as ECVRF-EDWARDS25519-SHA512-

ELL2. Specifications:

1. F: finite field F

2. flen: length of an element in F encoded as a string

3. E: an elliptic curve defined over F

4. ptLen: length of a string resulted from the encode of a point on E

5. G: subgroup of E of large prime order

6. n: prime order of group G

7. nLen: length of n, the smallest integer such that 2

8nLen

> n

8. cLen: length of c, a challenge value defined on VRF

9. cofactor: order of E divided by n

10. B: generator of group G

Algorithm 1 ECV RF _P rove

Input: VRF secret key S

, input α, generator point B of subgroup G of an elliptic curve

defined over a finite field.

Output: proof π

1: Use S

to derive VRF secret scalar x and VRF public key Y = x ∗ B

2: Calculate H = ECV RF _encode_to _curve(salt, alpha_string)

3: Calculate h_string = point_to_string(H)

4: Calculate Γ = x ∗ H

5: Calculate k = ECV RF _nonce_generation(SK, h_string)

6: Calculate c = ECV RF _challenge_generation(Y, H, Γ, k ∗ B, k ∗ H)

7: Calculate s = (k + c ∗ x) mod n

8: Calculate

π = point_to_string(Γ)||int_to_string(c, cLen)||int_to_string(s, nLen)

9: Return π

Algorithm 2 ECV RF _P roof _to_Hash

Input: VRF proof π, generator point B of subgroup G of an elliptic curve defined over a

finite field.

Output: output string beta

1: Calculate D = ECV RF _decode_proof(π)

2: if D is invalid then

3: Return INVALID

4: end if

5: Decode

(Γ

, c, s

) =

6: Calculate H = ECV RF _encode_to _curve(salt, alpha_string)

7: Calculate u = s ∗ B − c ∗ Y

Algorithm 3 ECV RF _V erif y

Input: VRF proof π, Public Key P

, input alpha, generator point B of subgroup G of an

elliptic curve defined over a finite field.

Output: Tuple (isV alid, beta)

1: Calculate Y = string_to_point(P

)

2: if Y is invalid then

3: Return (false, null)

4: end if

5: if D is invalid then

6: Return (false, null)

7: end if

8: Calculate D = ECV RF _decode_proof(π)

9: Decode (Γ, c, s) = D

10: Calculate H = ECV RF _encode_to_curve(salt, alpha_string)

11: Calculate U = s ∗ B − c ∗ Y

12: Calculate V = s ∗ H − c ∗ Γ

13: Calculate c

′

= ECV RF _challenge_g eneration(Y, H, Γ, U, V )

14: if c

′

= c then

15: Return (true, ECV RF _proof_to_hash(π))

16: else

17: Return (false, null)

18: end if

1.4.3 ECVRF auxilliary functions

Algorithm 4 ECV RF _Encode_T o_Curve

Input: encode _to_curve_salt, alpha

Output: hashed value H, a point in G

1: string_to_be_hashed = encode_to_curve_salt|| alpha_string

2: Calculate H = encode(string_to_be _hashed)

3: Return

Algorithm 5 follows the Edwards-Curve Digital Signature Algorithm mentioned in RFC8032

(23).

Algorithm 5 ECV RF _Nonce_Generation following RFC8032

Input: secret key S

, string h

tring

Output: integer k between 0 and n-1 (n being the order of G)

1: Calculate hashed_sk = Hash(S

)

2: Calculate

truncated_hashed_sk = hashed _sk_string[32]...hashed_sk_string[63]

3: Calculate k_string = Hash(truncated_hashed_sk_string||h_string)

4: Calculate k = string_to_int(k_string) mod q

5: Return

Algorithm 6 ECV RF _challenge_generation

Input: Elliptic curve points P1, P2, P3, P4, P5

Output: Challenge value x, an integer between 0 and 2

8cLen

− 1, with cLen the challenge

value of the VRF

1: Assign challenge_generation_domain_separator_front = 0x02

2: Assign suite_string = 0x04 according to ECVRF suite

ECVRF-EDWARDS25519-SHA512-ELL2

3: Assign str = suite_string||challenge_generation_domain_separator_f ront

4: for P

in [P

, P

] do

5: str = str||point_to_string(P

)

6: end for

7: Assign challenge_generation_domain_separator_back = 0x00

8: Assign str = str||challenge_generation_domain_separator_back

9: Calculate c_string = Hash ( str)

10: Calculate truncated_c_string = c_string[0]...c_string[cLen − 1]

11: Calculate c = string_to_int(truncated_c_string )

12: Return c

Algorithm 7 ECV RF _Decode_P roof

Input: VRF proof π, string length ptLen of a point encoded as string on E

Output: point Γ on E, integer c between 0 and 2

8cLen

− 1, integer s between 0 and n − 1

1: Assign gamma_string = π[0]...π[ptLen − 1]

2: Calculate c_string = π[ ptLen]...π[ptLen + cLen − 1]

3: Calculate s_string = π[ ptLen + cLen]...π[ptLen + cLen + nLen − 1]

4: Calculate Γ = string_to_point(gamma_string)

5: if isV alid(Γ) = f alse then

6: Return INVALID

7: end if

8: Calculate c = string_t

nt(c_string)

9: Calculate s = string_to_int(s_string)

10: if s > n then

11: Return INVALID

12: end if

13: Return (Γ, c, s)

1.4.4 Security Properties

The elliptic curve verifiable random function using the suite CVRF-EDWARDS25519-

SHA512- ELL2 - which means it will generate VRF using the elliptic curve Ed25519

and Elligator 2, elliptic curve points indistinguishable from uniform random string(8) - is

proven to satisfy all of the properties for verifiable random function, namely pseudoran-

domness, verifiability, uniqueness and collision resistance, if the values are generated in

an honest manner, and the verifier obtains specifications such as inputs, curve, prover’s

public key from publicly verifiable sources, rather than directly from the prover.

1.4.5 Chainlink's application of ECVRF

Chainlink VRF is a random number generation service developed by Chainlink (10).

This service enables users on blockchain to acquire safe and secure random numbers on

blockchains, namely Ethereum and Binance Smart Chain.

The user will first submit a request for a random number and a seed onto the blockchain

through Chainlink’s smart contract. Then, Chainlink will gather the requests, aggregate

them, and deliver them to Chainlink’s oracle, which is an off-chain external network of

nodes, this oracle will generate the random numbers from the seeds provided along with

the requests, verify the results, and submits the results back onto the blockchain through

Chainlink’s coordinator contract, where users can use the results on their own applications.

Recently, Chainlink VRF has introduced its v2 version, which creates a subscription

model for smart contracts, enabling seamless random number requests..

Figure 1.4.1: Chainlink’s VRF model (10)

This approach indeed could provide provable-fair and unpredictable random numbers,

but it relies heavily on Chainlink, and in case of service disruption (e.g. Chainlink decides

to temporarily suspend operation), users will be unable to carry on normal operations. Fur-

thermore, this approach limits users on Chainlink’s supported networks, which are mainly

EVM-based blockchains, not to mention the high cost associated with the requesting and

receiving of random numbers from Chainlink’s service.

Chapter 2

Possible Aacks on Blockchain System

In this chapter, we will discuss different attack vectors on blockchains, in particular the

possible attacks on network layer of the blockchain, how will it impact the blockchain as

a whole and the consensus algorithm of Proof-of-Stake blockchains in particular.

2.1 Aack Vectors on Blockchain

Broadly speaking, attacks on blockchain can be categorized in four distincts categories

(3).

1. Consensus-layer Attacks: which mainly consists of double-spending attacks and

their variants, such as Finney attacks, race attacks or 51% attacks. Consensus-layer

attacks aim to exploit the confirmation delays in consensus protocols to perform

malicious actions. This should be naturally mitigated with difficulty in block for-

mation and sufficient block confirmation before acknowledging the transactions on

blockchains.

2. Smart Contract Attacks: Smart contracts are the backbone of several prominent

blockchains, such as Binance Smart Chain and Ethereum. Smart Contract Attacks

focus on finding vulnerabilities in smart contracts, such as reentrancy or bugs to ex-

tract funds illegitimately. These attacks are prominent in EVM based blockchains,

and to some capabilities, Rust based smart contracts like CosmWasm. Decentral-

ized autonomous organization (DAO) attacks are one of the most prominent Smart

Contract based attacks, with the infamous The DAO Attack which costed over 70

million USD in damage. Randomization is also an easy target for attacks, since

blockchain is inherently deterministic, and any randomization attempt using only

public variables is susceptible to exploitation by malicious actors.

3. Wallet-based Attacks. In reality, there are two kinds of Wallet-based attacks. One

is through wallets such as Metamask, where malicious actors illegitimately obtain

users’ private keys and hold custody of their wallets. Another one is sort of like

smart contract attacks, but targeting multisig wallets - which are basically special

smart contracts. One such attack was the Parity Multisig Wallet attack, where an

attacker exploited ownership insecurity in Parity’s library contract to overwrite him-

self as the new owner, and gaining custody of all Parity multisig wallets.

4. Peer-to-Peer network-based Attacks: Blockchain in reality is a distributed system

run by nodes, and attacks on its network layer is severe to the nature of blockchains

as a whole. This thesis focuses on researching and remedying this kind of attack,

so this will be detailed further below in Section 2.2

2.2 Peer-to-Peer network-based Aacks

In this section, we will introduce four different kind of Peer-to-Peer network-based At-

tacks: Distributed Denial-of-Service, Sybil, Eclipse, and Routing attacks.

2.2.1 Distributed Denial-of-Service

This is the most well-known type of network-layer based attack, where adversaries try

to overload a system by flooding it with redundant requests that could overwhelm the

handling capacity of the system (a denial of service). A Distributed Denial-of-Service

attacks are organized attacks from a huge number of sources, which could be very hard to

mitigate.

2.2.2 Sybil Aack

A sybil attack is where an attacker controls a large number of fake identities to infiltrate

into a network and disrupt its decentralization and permissionless system. To outside

users, a network that has been infiltrated by a sybil attacker does not look any different

from a regurlar network, but in truth the sybil attacker has unfair advantage in the network

by controlling a majority of identities, and could perform malicious actions such as over-

throwing legitimate votes, or even validates fraud blocks. For example, in Figure 2.2.1,

the attacker manifests himself as 6 sybil nodes, achieving a total of 60% majority in the

consensus, practically performing a 51% overriding attack at all time.

On blockchain, Sybil attacks also manifest itself as the form of malicious users faking

multiple identities on blockchain to perform actions such as overwriting the majority of

votes on a DAO.

Figure 2.2.1: Sybil attack example

2.2.3 Eclipse Aack

Eclipse attack is a network-based attack that aims to isolate nodes from the entirety of the

decentralized network. This is enacted by overrunning the routing table of the targeted

node before forcing a restart, which will result in the victim node being forced to establish

a connection with the attacker with high probability. From here, the attacker will have full

control over the victim node’s information flow and could perform malicious activities

over the network. Due to the distributed nature of the blockchain, this attack method is

focused on single nodes instead of the entire blockchain network at once.

2.2.4 Routing Aack

Routing attack is where a malicious user tries to manipulate the incoming packets of a

node, by either separating the network into two ”partitions” that could not communicate

with each other, then sending manipulated packages to each side so that they could not

verify the integrity of the packets and would accept it as honest.

For example, in Figure 2.2.2, attackers only need to attack node A and node B to divide

the distributed network into two partitions with no means of cross-communication, thus

can manipulate information sent to each side of the partition

Figure 2.2.2: Routing attack example

2.3 Possible Aack Scenarios on Deterministic Proposer Se-

lection Algorithm

As mentioned above, Tendermint’s Proof of Stake consensus protocol selects its next pro-

poser by a deterministic round-robin algorithm, meaning with a given set of validators v,

anyone can calculate and determine the sequence of upcoming block proposer from any

height to any height of their choice. This leaves Tendermint’s consensus protocol vulner-

able to several particular types of network-layer attack vectors, namely the Eclipse Attack

and the Distributed Denial-of-Service Attack, especially with small-scale networks that

have a low number of validators and stable set of validators.

2.3.1 Eclipse Aack Scenario on Deterministic Proposer Selection Algo-

rithm

Figure 2.3.1: Normal operation of validators and proposer at height h

Figure 2.3.2: Eclipsed operation of validators and proposer at height h

In a normal configuration (Figure 2.3.1), a proposer would form a block then broadcast

the blocks to other validators on the blockchain via the Gossiping protocol. But, since

the sequence of block proposers is pre-determined, and block time of Tendermint-based

blockchains usually is static - 1 second, thus a coordinated adversary could determine

the next proposer on any block height ahead of any arbitrary amount of time, and could

”eclipse” the proposer at the exact moment (Figure 2.3.2).

In a larger scale Proof-of-Stake blockchains with many validators, this would prove

no more than an inconvenience since the vast majority of validators would just timeout

and a new round will begin, but in small scale blockchain, the attacker can forge enough

malicious ”eclipse nodes” that could override the proposer’s validator threshold, and fal-

sify transactions sending to the proposer, disrupting the network. Furthermore, repeatedly

eclipsing nodes (which is achievable when nodes are configured in close proximity .i.e. on

a local blockchain when nodes are in the same LAN) could severely disrupt the operation

of the blockchain, when validators keep timing out waiting for proposer of blocks.

2.3.2 DDoSAackScenario on Deterministic Proposer Selection Algorithm

Figure 2.3.3: DDoS operation of validators and proposer at height h round 0

Figure 2.3.4: DDoS operation of validators and proposer at height h round 1

Similar to Eclipse attack, because the sequence of block proposers is pre-determined, a

coordinated adversary could determine the next proposer on any block height ahead of any

arbitrary amount of time, and could perform a DDoS the proposer at the exact moment

(Figure 2.3.3).

This could even be extended so that the DDoS sequence could match the pattern of

proposer being chosen, with the predetermined time between each round being fixed by

Tendermint, perpetually locking the blockchain in a timing out loop. This attack is difficult

to perform on large scale networks since the nodes are more powerful and their physical lo-

cations are usually far apart enough to cause some coordination difficulty - but not entirely

impossible, if the attackers have enough resources distribute attacking bots near targeted

nodes and pre-programming the sequence of attacks to the attacking stations.

On the other hand, smaller scale blockchains are especially vulnerable to this type of at-

tack due to their limited size and node capabilities, not to mention nodes are usually placed

in close proximity. This attack is easier than performing a network-wide blockchain DDoS

in this scenario, since it costs very little resources, and flooding power is concentrated on

a single node.

2.4 Possible Aack Scenarios on Weak Randomization Algo-

rithm

Randomness generation on blockchain is a major concern, since there are a great deal of

services that could utilize randomness, such as games, lottery etc. Attempts were made to

recreate pseudorandom numbers on blockchain utilizing various variables that are readily

available and assumptively unpredictable such as blockhash and block timestamp.

But in truth, variables on blockchain are easy to predict, be manipulated and simu-

lated by the block creators (in certain EVMs based system, miners could possibly even

determine block timestamp themselves within reasonable range).

Figure 2.4.1: Weak randomness possible attack scenario

A possible attack scenario using weak randomization algorithm following the use of

block hash is as follows. The deployer deploys a high-stake lottery contract that uses a

future block hash at height h. When the time comes, the miner of height h could possibly

manipulate the block so that the blockhash is favorable to them, thus destroying the validity

of the lottery.

Because of this reason, a strong randomization scheme, which satisfies both secrecy

and verifiable properties is of great importance when considering applications in blockchain

2.5 Precedents

2.5.1 Network-layer Aack

The DDoS attack is, and has been, a major concern in cybersecurity as a whole, since it is

capable of disrupting digital services, which includes blockchain.

In 2022, Solana network suffered from a series of DDoS attacks which is so severe

that the blockchain had to be rolled back, and its token price on the market plummeted as

a result of distrust of investors. The incidents are caused by bots sending duplicated trans-

actions repeatedly to the proposer nodes, overloading their capabilities of acknowledging

and forming of blocks (11).

The aftermath did not stop at blocking users out of the blockchain, it also affected

majority of DeFi users from closing out their position on the blockchain, and as a result,

their position got liquefied since they could not add more collateral to their loans. A roll

back was thus forced, but it resulted in discontent among users towards Solana networks.

Arbitrum network - a layer 2 Ethereum network - also suffered from a particularly

nasty DDoS attack when it launched on September 2022. Although being promoted with

a huge network of validators, bots are still capabale of incapacitating Arbitrum to the point

of total network congestion for 4 hours after launch. Although it does not have the severe

consequence of Solana, Arbitrum’s attack still left users with discontent and discomfort,

affecting the operation of the blockchain as a whole.

On the other hand, there has been no major incident relating to Eclipse attack, but

reports of small scale Eclipse attack are numerous, and this vector is still extensively stud-

ied and analyzed by blockchain experts worldwide, with many warnings against Eclipse

attack by papers and journals (21) (28) (3).

2.5.2 Weak Randomization Aack

There are numerous dApps that utilizes weak randomization on Solidity and EVM based

blockchains which have been exploited, most of them using randomization for generating

NFTs of various rarities.

Most notably, cryptogs, a game of pogs on Ethereum, utilizes blockhash(block.number)

to decide the winner. This can be easily manipulated by the miners. Furthermore, this

blockhash can only record up to 255 blocks behind the latest block, further than that and

it will return 0 (22).

This resulted in massive loss for users as attackers could easily manipulate the con-

tracts, putting their pogs ahead of everyone else and withdrawing their pogs before other

users would have the chance to react.

As such, a strong randomization scheme on blockchain is vital in keeping a fair and

secured environment for participants, which will be discussed further below.

2.6 Solutions

The purpose of this thesis is to devise a solution for the above problems, by first utilizing

a strong randomization scheme - meaning, elliptic curve verifiable random function - to

choose the next proposer. This way, adversaries would not be able to determine the up-

coming proposer, and be able to disrupt the blockchain by matching the attack patterns to

blockchain consensus time.

At most, the adversaries could only focus attack on 1 node and fully block that node

outside of the blockchain ecosystem, and if they are lucky, that node could be the proposer

node, delaying the blockchain by 1 round.

Utilizing ECVRF also prevents nodes from exploiting weak randomness to manipu-

late selection algorithm. One possible scenario is one node could manipulate transactions

so that the blockhash always returns a value that will result in the consensus picking that

node again for the next round, if we use a weak randomization function such as the exam-

ples described in Subsection 2.5.2. Using ECVRF ensures that the random value is truly

pseudorandom, which means it cannot be denoted without the private key of the creator,

and public known inputs mean the creator could not manipulate the results according to

their intentions.

Furthermore, ECVRF in consensus protocol enables strong randomness usable in other

functionalities of the blockchain (.i.e. game smart contracts), which could enhance and

extend the usefulness of a blockchain with ECVRF-enabled.

Chapter 3

Designing the Consensus Protocol

In this chapter, we will propose a consensus protocol design that implements the Ellip-

tic Curve Verifiable Random Function, and propose a beacon chain model for Cosmos

Ecosystem using a VRF-enabled consensus protocol blockchain.

3.1 Proposal and PreVote Processes

Commit

Yes

Figure 3.1.1: Consensus process at a given block height h

Based on the possible attack patterns that stem from the deterministic nature of Tender-

mint’s block proposer selection algorithm mentioned above, we propose some improve-

ments in design toward block proposer selection procedure, which can help mitigate future

attacks, especially on small-scale blockchains with few validator nodes. The design is de-

scribed in Figure 3.1.1

In our protocol, the validators also participate in the consensus process by signing

votes for blocks proposed by the proposer, much like Tendermint protocol presented in

Chapter 2. Upon a new round of block formation at block height h, a new proposer for the

next block is chosen. Instead of utilizing a deterministic function to select the proposer,

the proposer is instead chosen by the following function:

proposer = getP roposer(v, t

h−1

, r) (3.1)

in which v is the validator set of the previous block (h-1), t

h−1

is the random number

generated and included in the previous block, and r is the current round of the height h.

Since the function getP roposer(v , t

h−1

, r) is deterministic and only cares about the

values v, t

h−1

and r which is publicly known, nodes can verify if they are selected inde-

pendently for that round, thus this step does not require extra communication step between

nodes. Then, the proposer will create a block from the transactions stored in the mempool

and propose this block to the consensus.

In addition to block formation, the proposer also needs to generate a random value t

This is performed by first creating the alpha input:

= keccak256(r, h − 1, t

h−1

) (3.2)

in which h−1 is the height of previous confirmed block (0 if it is the first block), and t

h−1

the random value of the previous confirmed block (0 if it is the first block). Keccak256 is a

secure hash algorithm that is based on sponge construction and demonstrates remarkable

resistance against different attacks (27). After that, the proposer combines m

with its

secret key S

to generate the proof as follows:

π = ECV RF _prove(S

, m

) (3.3)

Finally, the proposer confirms the final random value by the following formula:

= ECV RF _proof _to_hash(π) (3.4)

and attaches its public key P

and the result t

to the proposal, which are broadcasted over

the blockchain via the Gossip protocol to adjacent nodes. When each validator verifies

that over two-thirds of the nodes have acknowledged the proposal or a timeout limit has

been reached, the validator enters the prevote step.

In the prevote step, the validator verifies two components. First, it verifies that the pro-

posed block is a valid one, by running an external function isBlockV alid = validate(bl ock

If isBlockV alid = true, then the validator verifies the random number generated by the

proposer. This is performed by first computing the alpha input using function (3.2) then

the validator runs the following verification function:

(isV RF V alid, t

′

) = ECV RF _verif y(P

, π, m

) (3.5)

in which t

′

= ECV RF _proof _to_hash(π).

Since each combination of S

and m

generates a unique proof π, function (3.5) only

returns isVRFValid = true if the proof π (and, in turn, the value t

) is calculated in an

honest manner by the proposal. In the last stage, the validator needs to submit its deci-

sion. If both isBlockV alid and isV RF V alid return true and the value t

′

is equal to

, the validator thus will sign, submit a prevote for the proposed block and broadcast

this prevote to the adjacent validators through Gossip protocol. In any other case (e.g.

isV RF V alid returns false), the validator will sign a nil message and broadcast this pre-

vote to the blockchain.

The rest of the block formation will perform similar to Tendermint’s protocol. In the

beginning of the Precommit step, each validator will make a decision based on how many

prevotes that validator has received for the proposed block. If the prevote count is more

than

of total prevotes for the proposed block, the validator will sign and broadcast a

precommit for that particular block, and lock onto that block, releasing any prior locks in

the progress. If the node had received more than

of nil prevotes, it will broadcast a nil

precommit, and just unlock any locked block it has locked on before.

At the end of the Precommit step, each node will count the precommits it received

via the Gossip protocol. If there are more than

of precommits that are not nil for an

acceptable block, the validator will enter Commit step, otherwise it will ready for the next

round.

At the Commit step, the validator will sign and broadcast for the block it must have

received from the proposer, and then it will wait for other commits from other validators

on the blockchain. When

of the commits have been received, the validator will set the

CommitT ime to the current time, and enter N ewHeight step, ready to build a new block

to the blockchain. The N ewHeight step is a padding step that lasts for a fixed duration,

its purpose is for slow validators to be able to commit to the previous block.

Algorithm 8 PROPOSAL

Input: height h, transactions txs

, previous height h − 1, validator set v of block h − 1

and previous random number t

h−1

Output: proposal propose(h, r, block

, π

, t

) or timeout(round

1: When it is time for NewHeight:

2: Initialize round r with height h, transactions txs

, previous height h − 1, validator

set v and previous random number t

h−1

3: Calculate proposer p

(h,r)

by using getP roposer(v, t

h−1

, r)

4: if p

(h,r)

= p then

5: block

= createBlock(txs

)

6: m

= computeInput(r, h − 1, t

h−1

)

7: π

= ECV RF _prove(S

, m

)

8: t

= ECV RF _proof _to_hash(π

)

9: Broadcast propose(h, r, block

, π

, t

) to adjacent nodes

10: else if p

(h,r)

= p then

11: Prepare for timeout(round

)

12: end if

Algorithm 9 PREVOTE

Input: proposal propose(h, r, block

, π

, t

)

Output: prevote prevote(h

, r, id(block

))

1: When validator receives propose(h, r, block

, π

, t

2: Calculate P

by using getP K(p

(h,r)

)

3: Calculate isBlockV alid by using validate(block

)

4: Calculate m

by using computeInput(r, h − 1, t

h−1

)

5: Calculate (isV RF V alid, t

′

) by using ECV RF _verify(P

, π

, m

)

6: if isBlockV alid ∧ isV RF V alid ∧ t

′

= t

then

7: Broadcast prevote(h

, r, id(block

)) to adjacent nodes

▷ id(block) is the unique hash of block

8: else

9: Broadcast prevote(h

, r, nil) to adjacent nodes

10: end if

Algorithm 10 PRECOMMIT

Input: set of prevotes prevote(h

, r, id(block

)

Output: precommit precommit(h

, r, id(block

))

1: When validator receives

of prevotes.

2: if More than

of prevotes are nil then

3: Unlocks any locked block.

4: Broadcast precommit(h

, r, nil) to adjacent nodes

5: else if More than

of prevotes are id(block

) then

6: Lock on id(block

)

7: Broadcast precommit(h

, r, id(block

) to adjacent nodes

8: else if Less than or exactly

of prevotes are id(block

) ∧ Less than or exactly

prevotes are nil then

9: Does not broadcast or lock.

10: end if

At the end of each height, the block committed to the blockchain at height h will have

the random value t

and proof π, whose correctness is verified by participating validators,

inscribed onto it, and upon each of the rounds in the consensus process of the next block,

this value will be used to determine the next proposer.

Figure 3.1.2: Block structure of a VRF-enabled block

As shown in Figure 3.1.2, the block will contain a VRF segment that includes the VRF

random number t of that block, as well as the public key of the proposer and the proof pi to

prove the correctness of the VRF random number. Everything that is needed to verify the

correctness of t is present in the block, that means everyone would be able to double-check

and verify t at any moment by simply run the function m

= keccak256(r, h − 1, t

h−1

then (isV RF V alid, t

′

) = ECV RF _verif y(P

, π

, m

This process ensures that a malicious actor cannot predetermine block proposer of

height h for an indefinite amount of time ahead of height h, but can only know the pos-

sible proposer of height h ahead by at most height h − 1, preventing him from planning,

coordinating and scheduling attacks against upcoming proposers and disrupting the net-

work, ensuring the integrity of the system.

This model does not only work with Tendermint’s protocol, but theoretically could be

applicable to any Proof-of-Stake consensus protocol, since the application of ECVRF does

not depend on Tendermint’s functionalities. Other candidates that could apply ECVRF to

enhance security and privacy includes Tezos and Polkadot.

3.2 Random Module and Beacon Chain

Figure 3.2.1: Random module design

Another improvement that we have devised is the inclusion of the random module,

which retrieves the VRF numbers of the consensus layer and broadcasts it to the appli-

cation layer, allowing users to also utilize this random result. This design is described in

Figure 3.2.1

This module has the IBC capability of Cosmos, and is compatible with the CosmWasm

module (which is the Cosmos’ ecosystem implementation of smart contracts), as a result,

this module is capable of supplying random numbers to smart contracts deployed on the

blockchain ecosystem and enables this blockchain to act as a random beacon chain inside

the Cosmos Ecosystem. This means, that not only users are capable of deploying smart

contracts that use verifiable random numbers on this blockchain, but other chains’ users

can also tap into this blockchain to require a verifiable random number for personal use.

One example of how this module can be used is when a user, for example, Alice, wants

to deploy a lottery system, as shown in Figure 3.2.2. She first writes a smart contract,

then specifies which block height will be used for the random number retrieval (which, of

course, should be a future block, otherwise it will defeat the purpose of random number).

Then, at the time of the lottery draw, the smart contract retrieves the random number

from the predetermined block and calculates the outcome. Anyone could verify the

correctness of t

by simply calculating input m

and using it along with P

and π

In more detail, in the blockchain, Alice will deploy a smart contract at block i, that

designates the result will be taken from the random value generated from block j. The

smart contract then locks the lottery funds until at least block j. When block j is formed

and added to the blockchain, the smart contract then acquires t

from the block, which

could be verified easily by anyone participating in the system, and calculate the winner

based on that.

Figure 3.2.2: Example lottery design

One could argue that the validator can possibly manipulate the result of t

, but the

ECV RF _verif y(P

, π

, m

) function’s inputs are all determined and publicly known,

which means the outcome t

is impossible to manipulate unless the proposer intentionally

forfeits his rights to propose that block and wait for a better chance in the next round,

potentially facing a stake slash and still cannot ensure that the outcome will be favorable

to him. The only possible exploit is collusion between the validators, which would be

detrimental to Proof-of-Stake anyway.

This approach towards random number generation on blockchain is different from

Chainlink’s VRF method in two ways. Firstly, Chainlink VRF relies on a subset of external

actors, and from their consensus, delivers the random number onto the blockchain through

an oracle. Not only does this render users heavily relying on an external factor of the

blockchain and vulnerable to disruption (e.g. when Chainlink decides to go offline), but

it also incurs extra cost for users to pay for Chainlink’s services. On the other hand, the

proposed random beacon chain model’s random number generation is a by-product of the

consensus itself, whose validators have already been rewarded by the consensus algorithm,

thus users can use these random numbers without charge, and as long as all of the nodes

inside the random beacon chain is working properly, users will not have to worry about

service disruption. Secondly, the random beacon chain’s ECVRF construction uses the

Ed25519 elliptic curve instead of Chainlink’s secp256k1, which has been proven to house

numerous advantages, both in security and efficiency as described in Chapter 2.

3.3 Proposed Method Compared To Related Works

Since VRF is a thoroughly researched field, previous applications of VRF into the blockchain

spaces have been presented, such as Algorand or Polkadot, but they are substantially dif-

ferent from the proposed method above.

3.3.1 Algorand

Algorand also aims to solve the problem by incorporating VRFs into its blockchain scheme,

by using VRF during the selection process. The VRF functions similar to a lottery and is

used to choose leaders to propose a block and committee members to vote on a block. This

VRF output, when executed for an account, is used to sample from a binomial distribution

to emulate a call for every algo in a user’s account. The more algos in an account, the

greater chance the account has of being selected – it’s as if every algo in an account par-

ticipates in its own lottery. (15). This method is different from our approach, since instead

of selecting the proposer for the consensus mechanism, Algorand instead selects a set of

validators to validate for the proposed block. That means, if you are not selected as a val-

idator, you will not get validation rewards for that particular block, which is detrimental

for small stakers in the network. Furthermore, Algorand is its own standalone blockchain

and does not have the capabilities to interact with other blockchains, which will not be

helpful in the Cosmos ecosystem

3.3.2 Polkadot

Polkadot also has the idea of incorporating VRFs into the blockchain. Instead of deter-

ministically select a block proposer from the function, all of the validators will compute if

their number v is smaller than the network generated number T . That means there could

be many validators selected to produce a block, which requires extra works to select the

next block and does not provide useful work for the network as a whole. And the same

problem occured with Algorand, since Polkadot is a standalone blockchain and does not

have the capabilities to connect to other blockchains, the use of VRF is limited. (12)

There have been ideas raised for Tendermint consensus protocol, but all of them are

merely presented as ”open issues”, and as far as the research goes, there have not been any

research or proposed models to incorporate ECVRF into the Tendermint ecosystem and a

beacon chain model to connect the VRFs to other blockchains within the vicinity.

3.4 Method Advantages and Disadvantages

The proposed method houses several advantages over the normal Tendermint operations:

1. The proposed method has improved Tendermint’s consensus protocol, by adding a

VRF generation and verification protocol on block creation for choosing the next

proposer. This ensures that attackers could only have known the selected proposer

ahead of at most 1 block, ensuring the difficulty of organizing and orchestrating

attacks against the blockchain. The efficiency of attack resistance will be demon-

strated further below.

2. The method allows a way to retrieve the verified VRF to be used for random num-

bers over the blockchain, while using the efficient Ed25519 curve to compute.

Despite this, there are also numerous disadvantages that hinders the incorporation of

the proposed method on the blockchain space:

1. On a larger scale blockchain with hundreds of validators, the observed efficiency of

the novel protocol dwindles, since orchestrating a massive DDoS on such a networks

is nigh impossible either way. Still, this proposed protocol could protect a sole

validator from targeted eclipse attacks, preventing that sole node from being totally

isolated.

2. Incorporating the method into existing blockchains would require tremendous ef-

forts, since restarting a blockchain with a new protocol would require all validators

to rewrite the genesis configuration. As such, this protocol should only be applied

for new blockchains.

3. Although not significant, there is still a small computation overhead and network

latency for the computing and verification of verifiable random numbers, which

would be discussed further below.

Chapter 4

Implementation and Evaluation

To implement the proposed method as described in section 3, we constructed a prototype

blockchain and will assess it for the qualities of both its selection method correctness and

block formation time, then compare it to Tendermint’s.

4.1 Prototype Blockchain Creation

To create a prototype blockchain and implement the VRF-enabled consensus protocol, we

utilize the Cosmos-SDK, a SDK to build blockchains on Cosmos Ecosystem, and Tender-

mint Core, the original Tendermint consensus protocol. We then proceed to modify the

consensus programming of Tendermint Core to add the VRF implementation. These are all

written in golang. The VRF implementation suite of choice is ECVRF-EDWARDS25519-

SHA512-ELL2, an ECVRF implementation utilizing the curve Ed25519 and points ac-

cording to Elligator 2 standard, as it is the most secure and efficient suite.

In more detail, we modified the struct Block to contain VRF headings, and modified

Validators action to include the proposal action of calculating VRF number, validation of

incoming VRF number, and insert the validation into the struct, as shown in Figure 4.1.1

and Figure 4.1.2

This modified Tendermint Core are then rewired to the Cosmos-SDK, which, in turn,

is rewired into a fork of CosmWasm. This CosmWasm fork, or more precisely, the wasm

module, is also modified to accommodate the VRF number extracted from the consen-

sus protocol, that means (modified) cosmwasm smart contract library could extract these

Figure 4.1.1: Block struct in modified Tendermint Core

Figure 4.1.2: Vrf struct in modified Tendermint Core

Figure 4.1.3: Vrf struct in modified Tendermint Core

values from the blockchain and utilize it to their purpose, as shown in Figure 4.1.3.

4.2 Environmental Setup

All of the experiments are conducted on four Docker containers deployed on a local net-

work with four distinct IP addresses and ports to avoid network collision. All are run on

the same hardware configuration: a CPU of 2GHz Quad-Core Intel Core i5 and 16GB of

RAM.

The DDoS attacks are performed using Apache Benchmark (1), which simultaneously

generates 60.000 concurrent requests each interval to the targeted node IP address and

port. The number is chosen considering the limits of the testing environment’s bandwidth

and computer resources.

4.3 Correctness

To evaluate the proposed consensus protocol variant against a coordinated DDoS attack,

we ran a simulated DDoS attack against a prototype comprised of 4 nodes and then com-

pared it against Tendermint’s similar setup. Since Tendermint’s proposer selection algo-

rithm is deterministic and in a round-robin fashion, the coordinated attack will know be-

forehand which node is being selected next and is programmed in a predetermined pattern.

When determined a block height to start attacking, the attack algorithm will calculate the

0 200 400 600 800 1000

Round

2000

4000

6000

8000

10000

Block Formation Time (ms)

Figure 4.3.1: Average block formation time under coordinated DDoS attack of Tendermint

consensus protocol

designated block height’s proposer node and launch an attack on that node when the time

comes. After that, the attack algorithm will attack subsequent proposers at each timeout

interval according to the round-robin selection algorithm.

Because the proposed model’s selection algorithm uses VRF, the pattern cannot be

determined beforehand, thus we applied the same pattern as Tendermint’s attack to com-

pare the results. At a determined block height, the attack algorithm will pick the proposer

according to Tendermint’s selection algorithm, and then proceed with the attack accord-

ingly.

We then gathered the average block formation time of the nodes and created a scatter

plot. A block formation time of 10000ms means the protocol timed out waiting for the

block proposer to initialize a block.

From the results, we can observe that under coordinated attack, Tendermint’s chosen

proposal nodes mostly cannot perform their function properly, the blockchain constantly

reaches timeout and needs to advance to new rounds, significantly increasing block cre-

ation time. Meanwhile, due to the unpredictability of the new model’s consensus algo-

0 200 400 600 800 1000

Round

2000

4000

6000

8000

10000

Block Formation Time (ms)

Figure 4.3.2: Average block formation time under coordinated DDoS attack of VRF-

enabled consensus protocol

rithm, the coordinate attacks cannot always target the new model chain’s proposal nodes,

allowing the network to function properly even with one node losing its functionality.

As long as other nodes can still produce a block proposal, the blockchain can function

properly with one node down. There are still occasions when the proposal node is the

targeted node, and in such cases, the network will timeout and need to move to a new

round, but compared to Tendermint’s consensus protocol, the successful consensus rate is

significantly higher.

In more detail, out of 1000 rounds, 92.5% of Tendermint’s consensus protocol rounds

reached timeout without being able to finalize blocks when under coordinated attacks,

meanwhile the figure is only 52.8% with the proposed variant, as seen by the distributions

observed in Figure 4.3.1 and 4.3.2 - in which the red dots denote timed out rounds and the

blue dots denote the average block formation time of completed block.

4.4 Fairness

As discussed in Chapter 2, Proof-of-Stake selection process should satisfy two essential

qualities, Determinism and Fairness.

0 200 400 600 800 1000

Height

Node

Figure 4.4.1: Random beacon chain’s scatter plot of node selection over 1000 blocks for

4 nodes, each with 1 voting power

1. Determinism: The choice of implementing ECVRF using the elliptic curve already

ensures the determinism of the consensus, since function (3.2) and sequentially

function (3.3) are both deterministic. As long as the state of blockchain is repli-

cated from the genesis block, the sequence of random values t will be replicated

one by one.

2. Fairness: One of the key values of ECVRF lies in its full pseudorandomness, which

was proven by S. Goldberg et al (19). In short, ECVRF ensures that someone with-

out knowledge of secret key S

will not be able to distinguish the outcome t

from a

random value. Furthermore, the proposer cannot choose the input m

, but needs to

conspicuously perform a predetermined function (3.2) to generate the VRF number.

To further clarify, we first performed a pseudorandom distribution test, then we per-

formed a test on the prototype with 4 nodes and analyzed the results of block proposer

selection over a range of approximately 10,000 blocks multiple times to verify the fair-

ness of the consensus.

1 2 3 4 5 6 7

Node0

25.2%

(2481)

Node1

24.3%

(2392)

Node2

25.1%

(2469)

Node3

25.3%

(2486)

Figure 4.4.2: VRF-enabled consensus protocol’s percentage of node selection over 9852

blocks for 4 nodes, each with 1 voting power

1 2 3 4 5 6 7

Node0

6.7%

(681)

Node1

17.4%

(1782)

Node2

32.4%

(3310)

Node3

43.5%

(4451)

Figure 4.4.3: VRF-enabled consensus protocol’s percentage of node selection over 10224

blocks for 4 nodes, with voting powers equal to 1, 3, 5, 7 respectively

Table 4.5.1: Average block finalization duration of nodes over 10000 blocks (in ms)

Node VRF-powered Chain Tendermint

Node 0 958.333121780022 945.4388912947659

Node 1 958.1333696459159 946.0899973030309

Node 2 958.2167081699193 946.0843910854002

Node 3 958.4829165905359 946.0987231019282

From the scatter plot depicted in Figure 4.4.1, it is shown that the algorithm will dis-

tribute the selection throughout 4 nodes in a fairly even manner, without many gaps or

clusters. Over a longer period of time, this distribution will gradually reach a discrete

uniform distribution.

This is backed by the data shown in Figure 4.4.2 and 4.4.3. With a testing sample of

approximately 10,000 blocks, the chance of a block being selected as the proposer is an

approximation of the function:

∑

n−1

i=0

(4.1)

in which p

is the voting power of node i. In an arbitrarily long sequence of blocks, this ap-

proximation should gradually reach the ratio of the round-robin algorithm that Tendermint

has developed.

For the above experiments, we see that this random beacon chain model’s consensus

algorithm satisfies both determinism and fairness for the proposer selection process, and

adds an extra layer of protection against potential attack vectors.

4.5 Performance

To evaluate the performance of this random beacon chain model’s consensus algorithm

and the impact of VRF calculation, we will conduct several tests over the length of ap-

proximately 10000 blocks to measure the block finalization time of each node, from the

initialization of block height h (i.e. upon NewHeight trigger) to the initialization of block

height h + 1. This is evaluated on a constant input stream of roughly 3 transactions per

second.

Since validator nodes can perform the selection function independently, there exists

no extra communication delay between nodes, and there is only a slight overhead of 12ms

0 1000 2000 3000 4000 5000

Round

600

700

800

900

1000

Block Formation Time (ms)

Figure 4.5.1: VRF-enabled consensus protocol’s node0 block formation time measure-

ments over length of 5000 blocks

for each node due to the calculation and verification of VRF, as shown in Table 4.5.1.

We also plotted a graph of individual duration measurements of block formation time

on two nodes over 5000 blocks. From Figure 4.5.1 and 4.5.2, we can see that the block

finalization duration of node0 and node1 stay mostly stable throughout a sequence of 5000

blocks and a constant input rate of 3 transactions per second, with some occasional anoma-

lies, but there recorded no timeout and no severely delayed block finalization time.

From these results, we concluded that the addition of ECVRF into the consensus pro-

cedure does not cause critical degradation or severe delay in block formation, and the

performance of the random beacon chain’s consensus algorithm is comparable to that of

Tendermint’s while keeping the selection procedure safer and more secure.

0 1000 2000 3000 4000 5000

Round

600

700

800

900

1000

Block Formation Time (ms)

Figure 4.5.2: VRF-enabled consensus protocol’s node1 block formation time measure-

ments over length of 5000 blocks

Conclusion

This thesis has demonstrated the outline of the problems with the current Proof-of-Stake

consensus protocol, in particular Tendermint consensus protocl, and proposed a new con-

sensus design powered by a provably fair Elliptic Curve Verifiable Random Function,

which, as demonstrated through experiments, possesses the capability to mitigate network-

based attack vectors while retaining the determinism, fairness, and performance of the

Tendermint consensus protocol.

Furthermore, the preinstalled random module built underlying the Cosmwasm module

allows this random beacon chain to act as a random beacon chain, both to serve provably

fair random numbers to smart contracts deployed within the network and to serve random

numbers for adjacent blockchains throughout the Cosmos Ecosystem through the IBC

protocol.

Future works in this area involve developing on-demand number generation requests,

i.e. allowing validators to process random number requests from smart contracts much like

Chainlink’s model, and aiming to further improve the performance of this novel random

beacon chain model.

Bibliography

[1] Apache http server benchmarking tool, 2023. Last accessed: 2023-09-12. URL:

https://httpd.apache.org/docs/2.4/programs/ab.html.

[2] Chainlinkvrfcoordinator smart contract, 2023. Last ac-

cessed: 2023-09-12. URL: https://bscscan.com/address/

0xc587d9053cd1118f25F645F9E08BB98c9712A4EE.

[3] Shubhani Aggarwal and Neeraj Kumar. Chapter twenty - attacks on blockchain

- working model. In Shubhani Aggarwal, Neeraj Kumar, and Pethuru Raj, ed-

itors, The Blockchain Technology for Secure and Smart Applications across In-

dustry Verticals, volume 121 of Advances in Computers, pages 399–410. Else-

vier, 2021. URL: https://www.sciencedirect.com/science/article/pii/

S0065245820300759, doi:10.1016/bs.adcom.2020.08.020.

[4] Peter Alleman. Randomness and games on ethereum, 2021. URL: https://

crypto.unibe.ch/archive/theses/2021.msc.peter.allemann.pdf.

[5] Victor Allombert, Mathias Bourgoin, and Julien Tesson. Introduction to the tezos

blockchain. pages 1–10, 07 2019. doi:10.1109/HPCS48598.2019.9188227.

[6] Antonina Begicheva and A Kofman. Fair proof of stake. 05 2018. doi:10.13140/

RG.2.2.11204.37765.

[7] Daniel J. Bernstein. Curve25519: New diffie-hellman speed records. In Moti Yung,

Yevgeniy Dodis, Aggelos Kiayias, and Tal Malkin, editors, Public Key Cryptography

- PKC 2006, pages 207–228, Berlin, Heidelberg, 2006. Springer Berlin Heidelberg.

[8] Daniel J Bernstein, Mike Hamburg, Anna Krasnova, and Tanja Lange. Elligator:

elliptic-curve points indistinguishable from uniform random strings. In Proceed-

ings of the 2013 ACM SIGSAC conference on Computer & communications security,

pages 967–980, 2013.

[9] Daniel J. Bernstein and Tanja Lange. Faster addition and doubling on elliptic curves.

In Kaoru Kurosawa, editor, Advances in Cryptology – ASIACRYPT 2007, pages 29–

50, Berlin, Heidelberg, 2007. Springer Berlin Heidelberg.

[10] Lorenz et al. Breidenbach. Chainlink 2.0: Next steps in the evolution of de-

centralized oracle network, 2021. URL: https://naorib.ir/white-paper/

chinlink-whitepaper.pdf.

[11] Quarmby Brian. Solana hit with another network incident causing de-

graded performance, 2022. URL: https://cointelegraph.com/news/

solana-hit-with-another-network-incident-causing-degraded-performance.

[12] Jeff Burdges, Alfonso Cevallos, Peter Czaban, Rob Habermeier, Syed Hosseini,

Fabio Lama, Handan Kilinc Alper, Ximin Luo, Fatemeh Shirazi, Alistair Stew-

art, and Gavin Wood. Overview of polkadot and its design considerations, 2020.

arXiv:arXiv:2005.13456.

[13] Beekhuizen Carl. Ethereum’s energy usage will soon decrease by 99.95

percent, 2021. URL: https://blog.ethereum.org/2021/05/18/

country-power-no-more.

[14] Krishnendu Chatterjee, Amir Kafshdar Goharshady, and Arash Pourdamghani.

Probabilistic smart contracts: Secure randomness on the blockchain. In 2019 IEEE

International Conference on Blockchain and Cryptocurrency (ICBC), pages 403–

412, 2019. doi:10.1109/BLOC.2019.8751326.

[15] Jing Chen and Silvio Micali. Algorand: A secure and efficient distributed ledger.

Theoretical Computer Science, 777:155–183, 2019. In memory of Maurice Ni-

vat, a founding father of Theoretical Computer Science - Part I. URL: https://

www.sciencedirect.com/science/article/pii/S030439751930091X, doi:

10.1016/j.tcs.2019.02.001.

[16] Meryem Cherkaoui Semmouni, Nitaj Abderrahmane, and Mostafa Belka-

smi. Bitcoin security with a twisted edwards curve. Technical report,

2019. URL: https://normandie-univ.hal.science/hal-02320909v1/file/

EdwardsBitcoinFinal-V3.pdf.

[17] Yevgeniy Dodis and Aleksandr Yampolskiy. A verifiable random function with short

proofs and keys. In Serge Vaudenay, editor, Public Key Cryptography - PKC 2005,

pages 416–431, Berlin, Heidelberg, 2005. Springer Berlin Heidelberg.

[18] Johnson Don, Menezes Alfred, and Vanstone Scott. The elliptic curve digital signa-

ture algorithm (ecdsa). In International Journal of Information Security. Springer,

2001.

[19] S. Golberg and L. Reyzin. Verifiable random function. Technical report, 2023. URL:

https://www.rfc-editor.org/rfc/rfc9381.pdf.

[20] M. Edwards Harold. A normal form for elliptic curves. In Bulletin of the American

Mathematical Society 44, pages 393–422. AMS, 2007.

[21] Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg. Eclipse attacks

on Bitcoin’s Peer-to-Peer network. In 24th USENIX Security Symposium (USENIX

Security 15), pages 129–144, Washington, D.C., August 2015. USENIX Asso-

ciation. URL: https://www.usenix.org/conference/usenixsecurity15/

technical-sessions/presentation/heilman.

[22] Song Jonghyuk. Attack on pseudo-random number generator(prng)

used in cryptogs, an ethereum (cve-2018–14715), 2018. Last ac-

cessed: 1-10-2023. URL: https://medium.com/coinmonks/

attack-on-pseudo-random-number-generator-prng-used-in-cryptogs-an-ethereum-cve-2018-14715-f63a51ac2eb9.

[23] Simon Josefsson and Ilari Liusvaara. Edwards-Curve Digital Signature Algorithm

(EdDSA). RFC 8032, January 2017. URL: https://www.rfc-editor.org/

info/rfc8032, doi:10.17487/RFC8032.

[24] Aggelos Kiayias, Alexander Russell, Bernardo David, and Roman Oliynykov.

Ouroboros: A provably secure proof-of-stake blockchain protocol. In Jonathan Katz

and Hovav Shacham, editors, Advances in Cryptology – CRYPTO 2017, pages 357–

388, Cham, 2017. Springer International Publishing.

[25] Jae Kwon. Tendermint: Consensus without mining. Technical report, 2014. URL:

https://tendermint.com/static/docs/tendermint.pdf.

[26] Jae Kwon and Ethan Buchman. Cosmos whitepaper, 2019. URL:

https://wikibitimg.fx994.com/attach/2020/12/16623142020/

WBE16623142020_55300.pdf.

[27] Jiasong Liu. Digital signature and hash algorithms used in Bitcoin and Ethereum.

In Shuhong Ba and Fan Zhou, editors, Third International Conference on Ma-

chine Learning and Computer Application (ICMLCA 2022), volume 12636, page

126365H. International Society for Optics and Photonics, SPIE, 2023. doi:10.

1117/12.2675431.

[28] Yuval Marcus, Ethan Heilman, and Sharon Goldberg. Low-resource eclipse attacks

on ethereum’s peer-to-peer network. Cryptology ePrint Archive, Paper 2018/236,

2018. https://eprint.iacr.org/2018/236. URL: https://eprint.iacr.

org/2018/236.

[29] S. Micali, M. Rabin, and S. Vadhan. Verifiable random functions. In 40th Annual

Symposium on Foundations of Computer Science (Cat. No.99CB37039), pages 120–

130, 1999. doi:10.1109/SFFCS.1999.814584.

[30] P.R. Nair and D.R. Dorai. Evaluation of performance and security of proof of work

and proof of stake using blockchai. In Third International Conference on Intelligent

Communication Technologies and Virtual Mobile Networks, pages 279–283. IEEE,

2019.

[31] Cong T. Nguyen, Dinh Thai Hoang, Diep N. Nguyen, Dusit Niyato, Huynh Tuong

Nguyen, and Eryk Dutkiewicz. Proof-of-stake consensus mechanisms for future

blockchain networks: Fundamentals, applications and opportunities. IEEE Access,

7:85727–85745, 2019. doi:10.1109/ACCESS.2019.2925010.

[32] Moritz Platt, Johannes Sedlmeir, Daniel Platt, Jiahua Xu, Paolo Tasca, Nikhil

Vadgama, and Juan Ignacio Ibañez. The energy footprint of blockchain consensus

mechanisms beyond proof-of-work. In 2021 IEEE 21st International Conference on

Software Quality, Reliability and Security Companion (QRS-C), pages 1135–1144,

2021. doi:10.1109/QRS-C55045.2021.00168.

[33] Nakamoto Satoshi. Bitcoin: A peer-to-peer electronic cash system, 2008. URL:

https://bitcoin.org/bitcoin.pdf.

Appendix A

Prototype blockchain architecture

In this thesis, Cosmos-SDK, Tendermint Core and CosmWasm is used and modified heav-

ily. This appendix will display the overall architecture of the components that made up

the overall structure of the prototype blockchain, and where the modifications took place.

Figure A.0.1: Prototype blockchain overall architecture

As shown in Figure A.0.1, the prototype blockchain core is the modified Tendermint

Core, which houses the VRF algorithm. The ECVRF generation and verification changes

happen here. It connects to Cosmos-SDK via Application BlockChain Interface (ABCI),

and sends information about the blocks to the application layers. The smart contracts

that are deployed will connect to the cosmwasm module, and extracts the random number

from the environment housed in the core of the module, a modified cosmwasmvm. Since

cosmwasm is fully capable of InterBlockchain Communication, this module will enable

other smart contracts from other blockchains to interact and extracts the random number

housed in the prototype blockchain to gain their own use.